Summary

Added an HTML visual response mode for chat.

This change adds a persisted chat input toggle using the Blocks animated icon. When enabled, chat requests send htmlVisualPrompt, and the backend injects a request-level system instruction without modifying the visible user message or stored conversation content. The injected prompt supports Chinese and English variants based on the current user message language.

It also improves inline HTML rendering for Markdown responses with a constrained allowlist and style sanitizer, so safe inline visual layouts can render inside normal chat content while blocking high-risk HTML/CSS patterns.

Change type

• Bug fix
• Feature
• Documentation
• Refactor
• Configuration / deployment
• Security hardening
• Other

Affected areas

• Frontend / UI
• Backend / API
• Authentication / authorization
• Conversations / streaming
• Files / RAG / extraction
• Model routing / providers
• MCP / tools
• Billing / payments
• Admin console
• Deployment / Docker / configuration
• Documentation

Verification

• cd frontend && pnpm lint
• cd frontend && pnpm build
• cd backend && go test ./internal/application/conversation ./internal/transport/http/conversation
• cd backend && go test ./...
• cd backend && make swagger
• git diff --check

Screenshots, API examples, or logs

Chat request payload now supports:

{
  "contentType": "text",
  "content": "解释一下大气循环",
  "model": "example-model",
  "htmlVisualPrompt": true
}

Configuration, migration, and compatibility notes

API changes: SendMessageRequest adds optional htmlVisualPrompt.

Generated Swagger was updated.

Database migrations: None.

Deployment changes: None.

Backward compatibility: Existing clients remain compatible because the new request field is optional and defaults to disabled.

Documentation

• Documentation is not needed for this change.
• Documentation was updated.
• Documentation still needs to be updated.

Security and privacy

• No secrets, tokens, credentials, local config, or personal data are included.
• User data access remains scoped by authenticated user context unless an admin-only path explicitly requires broader access.
• Security-sensitive behavior was reviewed, including authentication, authorization, provider routing, file processing, billing, and admin APIs where relevant.

Checklist

• I searched existing issues and pull requests.
• Changes are focused and do not include unrelated refactors.
• Tests or static verification were run where practical.
• User-facing behavior, deployment steps, API contracts, or configuration changes are documented.
• Generated artifacts are included only when this project explicitly requires them.
• Caches, build output, .pyc files, .env files, and local storage data are not committed.